本文重點

1. 開始規劃Namespace原則
2. Case Study - 以.NET MVC Framework為例
3. 魯妹喇低賽

專案建置之後，我們開始寫程式新增的第一個項目

應該是Namespace吧，至少我是這樣子

還是有人先把程式都寫完再做分類的???

所以Types設計原則就從Namespace的規劃開始吧

開始規劃Namespace

還記得設計Framework的基本原則中的第四點『使用分層架構開發』嗎？

開發一個大架構的framework之前

必須先把Namespace架構規範好

就像要塞滿一個空的衣櫃一樣

哪一層放上衣，哪個層放下著

上衣又分T Shirt, 襯衫；下著又分褲裝跟裙裝

一目了然才不會手足無措，以下就是沒有做好規劃的悲劇

由上而下(top-down)設計可以幫助namespace分類

Namesapce 建立的幾個原則如下

1. 做個namespace架構圖，把相關的功能放一起，並且使用sub namespace做分類
   namespace架構圖，可以幫助理解整個framework結構，也可以避免namespace與type的名稱衝突，是見重要的工作。

2. 但是不要太多層namespace

3. 也不要太多namespace
   以common功能為例，如果是整個freamwork都會用到的共通功能，實在不需要再針對不同的功能屬性分不同的namespace存放。

4. 主要情境之外的分支情境，不要跟主程式放在同一個namespace

關於subnamespace有幾個共通規範如下

1. .Dsign ：放設計階段程式（Design-time-only）
   設計階段意指，需要使用者實作，擴充的types (這部份帶確認說明是否正確）

System.Diagnostics.Design
System.Windows.Forms.Design 

2. .Permissions : 權限相關程式

3. .Interop : 有互動的程式

System.IO.Interop

Case Study

翻譯就到此為止吧，接著讓我們看看人家是怎麼做的

以.NET MVC Framework為範例，Namespace結構如下

以System.Web.Mvc為root，下面只有6個subnamespace，看起來真精簡

但是看System.Web.Mvc的內容時，差點吐血

https://msdn.microsoft.com/zh-tw/library/system.web.mvc(v=vs.118).aspx

不是說一個namespace不要超過500個types嗎？

他確實不超過500個，一共244個Types

看起來似乎把所有MVC Framework的主程式都寫在同一個namespace了

而AjaxHelper，AjaxRequestExtensions並沒有掛在Ajax了subnamespace下

這些Ajax相關程式，是在基礎架構執行Ajax中的核心程式

更方便使用或取得framework執行中的一些資料，ex: ViewData之類的

Ajax subnamespace則是放ActionLink、RouteLink這些擴充的功能

剛好符合前面說的

為主情境寫程式，有其他特殊情況時，放在另一個namespace

(待續與待確認)

參考資料:
https://msdn.microsoft.com/zh-tw/library/system.web.mvc(v=vs.118).aspx

喇低賽

繼上次硬表肌的故事後

小妹的魯妹又強迫小妹在鐵人po他的職場小故事

希望這不要變成本年度的鐵人常態

今天要講的是一個差點多元成家的故事

這邊做一下前情提要，魯妹是一位物理治療師

不是按摩師，不是電療師，也不是熱敷師

是一個經過四年大學與兩年研究所加實習嚴格訓練出來的專業物理治療師

如此一位學歷經歷輝煌的治療師某天收到來自急診的患者（男）

據悉，這位患者在車禍後被送到急診室時

一直吵著要打電話給女友，還把女友電話背出來要人家幫忙打

打過去後，急診室傳出電話鈴聲

在朋友與家人面前，接電話的是急診現場探望患者的其中一個朋友（男）

用這招告白也太犯規了吧！！！

但事後，患者完全不記得急診時候發生的事

這就是今天魯妹要我po的失憶的故事，真令人失意